שיעור מספר 8: "ירושה נכונה" )II )הורשה בית הספר למדעי המחשב
היום בשיעור חזרה על איטרטורים מחלקות מופשטות טיפוסי זמן ריצה 2
איטרטורים - תזכורת 3
מדוע יש צורך בשני מנשקים? המנשק Iterable מתאר את האובייקט עליו נרצה לעבור בלולאה )בד"כ אוסף כלשהו(. משמעותו: ניתן לבצע על אובייקט זה מעבר באמצעות לולאת each for המנשק Iterable מכיר את המנשק Iterator ומחויב להשתמש בו. המנשק Iterator מתאר אובייקט שונה מהאוסף עליו נרצה לעבור בלולאה. לכל אוסף ניתן להגדיר מספר איטרטורים, כל אחד יעבור בסדר\חוקיות אחרת למשל, מהסוף להתחלה, בדילוגים, וכו'. בפרט, ניתן לכתוב Iterator לאובייקט שאינו Iterable )אם זה הגיוני, כמובן( 4
Comparable and Comparator נרצה להגדיר סדר על אובייקטים מסוג Rectangle לצורך כך, נדרשת פונקציה שתקבע עבור כל זוג אובייקטים,o1 o2 מטיפוס Rectangle מהו היחס ביניהם, מבין שלוש אפשרויות: o1 גדול מ o2. שווה ל o2. o1 o1 קטן מ o2. 5
Comparable<T> המנשק Comparable<T> יתאר את האובייקט אותו נרצה להשוות )למשל, את.)Rectangle T מציין את המחלקה אליה נרצה להשוות את Rectangle בד"כ T יהיה זהה לטיפוס של האובייקט עצמו, כלומר public class Rectangle implements Comparable<Rectangle> 6
Comparator<T> המנשק Comparator<T> מתאר אובייקטים אשר משמשים להשוואת אובייקטים מטיפוס T האחד לשני. דוגמא להגדרת אובייקט שהוא :Comparator public class RectangleComparator implements Comparator<Rectangle> )*( למנשק זה קיימים שירותים סטטים\דיפולטיים נוספים אשר אינם מתוארים בשקף. מומלץ 7 לעיין בתיעוד המלא.
מדוע יש צורך בשני המנשקים? בדיוק כמו במקרה של Iterable ו,Iterator מנשק אחד מתאר את האובייקט עצמו )"בר השוואה"( והשני מאפשר להגדיר מחלקות שיכולות להשוות בין עצמים לפי קריטריונים שונים. בשונה מ Iterable שמשתמש ב Iterator )זהו ערך ההחזרה של הפונקציה,)iterator() המנשקים Comparable ו Comparator אינם משתמשים האחד בשני. 8
מנשקים ויחס ירושה כשם ששתי מחלקות מקיימות יחס ירושה כך גם שני מנשקים יכולים לקיים את אותו היחס מנשק, לעומת מחלקה רגיל, כן יכול לרשת מספר מנשקים. בדיוק כשם שמחלקה יכולה לממש מספר מנשקים מחלקה המממשת מנשק מחויבת לממש את כל המתודות של אותו מנשק וכל המתודות שהוגדרו בהוריו לדוגמא: סוגי מחסניות <<interface>> IStack <<interface>> IBoundedStack <<interface>> IUnBoundedStack <<interface>> ISumStack 9
Collection Interfaces(partial) Unordered Rejects duplicates Unordered Rejects duplicates <<interface>> Collection <<interface>> Map <<interface>> Set <<interface>> List <<interface>> Queue <<interface>> SortedMap Ordered Allows duplicates FIFO Order Allows duplicates Ordered Rejects duplicates <<interface>> SortedSet Ordered Rejects duplicates 10
היררכיות ירושה מחלקות רבות במערכות מונחות עצמים הן חלק מ"עצי ירושה" או "היררכיות ירושה" שורש העץ מבטא קונספט כללי וככל שיורדים במורד עץ הירושה המחלקות מייצגות רעיונות צרים יותר למרות שבשפת Java בחרו לאמר שמחלקה יורשת מרחיבה מחלקת בסיס, הרי שבמובן מסוים היא מצמצמת את קבוצת העצמים שהיא מתארת 11
אמא יש רק אחת נדגיש, כי לכל מחלקה יש מחלקת בסיס אחת בדיוק, ועל כן גרף הירושה הוא בעצם עץ )ששורשו המחלקה )Object מימוש מנשקים אינו חלק ממנגנון הירושה זאת על אף שבין מנשקים לבין עצמם יש יחסי ירושה דוגמא לעץ ירושה: צורות גיאומטריות במישור 12
היררכית מחלקות ומנשקים <<interface>> Shape Ellipse Polygon Circle Trapezoid Parallelogram Triangle Diamond Rectangle 13
abstract classes למצולע )polygon( ולאליפסה יש צבע עץ הירושה כפי שמצויר בשקף הקודם, יגרום לשכפול קוד )השדה color והמתודות ישוכפלו ויתוחזקו פעמיים( מחד, לא ניתן להוסיף למנשק שדות או מימושי מתודות מאידך, אם ניצור לשתי המחלקות מחלקה שהיא אב משותף מה יהיו מימושיו עבור היקף )דרך חישוב ההיקף עבור מצולע כלשהו ועבור אליפסה כלשהי שונה בתכלית( לשם כך קיימת המחלקה המופשטת class( )abstract מחלקה עם מימוש חלקי 14
abstract classes מחלקה מופשטת דומה למחלקה רגילה עם הסייגים הבאים: ניתן לא לממש מתודות שהגיעו בירושה ממחלקת בסיס או מנשקים ניתן להכריז על מתודות חדשות ולא לממשן לא ניתן ליצור מופעים של מחלקה מופשטת במחלקה מופשטת ניתן לממש מתודות ולהגדיר שדות מחלקות מופשטות משמשות כבסיס משותף למחלקות יורשות לצורך חיסכון בשכפול קוד נגדיר את המחלקה AbstractShape 15
היררכית מחלקות ומנשקים <<interface>> IShape <<abstract>> AbstractShape Ellipse Polygon Circle Trapezoid Parallelogram Triangle Diamond Rectangle 16
המנשק Shape public interface IShape { public double perimeter(); public void display(); public void rotate(ipoint center, double angle); public void translate(ipoint p); public Color getcolor(); public void setcolor(color c); //... 17
המחלקה המופשטת AbstractShape public abstract class AbstractShape implements IShape { protected Color color ; public Color getcolor() { return color ; public void setcolor(color c) { color = c ; המחלקה מממשת רק חלק מן המתודות של המנשק כדי לחסוך שכפול קוד ב"מורד ההיררכיה" את המתודות הלא ממומשות היא מציינת ב abstract public abstract void display(); public abstract double perimeter(); public abstract void rotate(ipoint center, double angle); public abstract void translate(ipoint p); 18
המחלקה המופשטת AbstractShape public abstract class AbstractShape implements IShape { protected Color color ; public Color getcolor() { return color ; public void setcolor(color c) { color = c ; אפשר לוותר על ההצהרה על מתודות לא ממומשות המחלקה שתירש מ AbstractShape תצטרך לממש את המתודות של Shape שהיא לא מימשה. 19
הגדרת בנאי במחלקה מופשטת public abstract class AbstractShape implements IShape { protected Color color ; public AbstractShape (Color c) { this.color = c ; public Color getcolor() { return color ; public void setcolor(color c) { color = c ; תוכנה 1 בשפת Java ניתן )ורצוי!( להגדיר בנאים במחלקה מופשטת על אף שלא ניתן לייצר מופעים של המחלקה, הבנאי יקרא מתוך בנאים של המחלקות היורשות )קריאות )super ויחסכו בשכפול קוד בין היורשות. 20
המחלקה Polygon public class Polygon extends AbstractShape { public Polygon(Color c, IPoint vertices) { super(c); // add vertices to this.vertices... public double perimeter() {... public void display() {... public void rotate(ipoint center, double angle) {... public void translate(ipoint p) {... public int count() { return vertices.size(); private List<IPoint> vertices; 21
דיון: מדוע צריך מחלקות אבסטרקטיות ב?Java 8 החל מ,Java 8 מנשק יכול להכיל מתודות מופע ממומשות )מתודות.)default על פניו יש עדיפות לשימוש במנשקים ובמתודות :default לעומת ירושה, אין הגבלה על מספק המנשקים שאותם מחלקה יכולה לממש. היתרון הגדול של מחלקה אבסטרקטית שדות! ניתן להגדיר בנאים, יתרון נוסף וכן מתודות שמשתמשות בשדות. ניתן לממש מתודות בניראויות שונות. 22
תפסת מרובה לא תפסת public class MyClass implements I1, I2{ public interface I1{ default void func() { System.out.println("I1"); public interface I2{ default void func() { System.out.println("I2"); המחלקה MyClass אינה מתקמפלת. אמנם אין אף מתודה אבסטרקטית שהיא צריכה לממש, אבל יש התנגשות בין שני המימושים של.func 23
public class MyClass implements I1, I2{ @Override public void func() { System.out.println("MyClass"); I1.super.func(); I2.super.func(); public interface I1{ default void func() { System.out.println("I1"); הפתרון: המחלקה MyClass חייבת לפתור את העמימות בכך שתממש בעצמה את השירות.func במימוש זה ניתן להשתמש במימושים של I1 ו\או של I2 )או להתעלם מהם לחלוטין(. public interface I2{ default void func() { System.out.println("I2"); 24
מחלקות מופשטות ומנשקים מנשקים: כאשר מגדירים מנשק ניתן למקבל את תהליך הפיתוח: צוות שיממש את המנשק במקביל לצוות שישתמש במנשק בפרט ניתן להגדיר תקנים על בסיס אוסף של מנשקים )למשל: )JDBC קוד לקוח שנכתב לעבוד עם מנשק כלשהו ימשיך לרוץ גם אם יועבר לו כארגומנט עצם ממחלקה חדשה המממשת את אותו המנשק כאשר מחלקה מממשת מנשק אחד או יותר, היא נהנית מכל פונקציות השרות אשר כבר נכתבו עבור אותם מנשקים )למשל: )Comparable הורשה: שימוש חוזר בקוד של מחלקה קיימת לצורך הוספה או שינוי פונקציונליות )ColoredRectangle, SmartTurtle )למשל: יצירת היררכיית טיפוסים, כאשר קוד משותף לכמה טיפוסים נמצא בהורה משותף שלהם )למשל )AbstractShape 25
לסיכום מנשק קוד לקוח מחלקת ספק מחלקת ספק 2 מחלקת ספק 3 26
לסיכום מנשק קוד לקוח מחלקה מופשטת מחלקת ספק מחלקת ספק 2 מחלקת ספק 3 27
טיפוסי זמן ריצה בשל הפולימורפיזם ב Java אנו לא יודעים מה הטיפוס המדויק של עצמים הטיפוס הדינאמי עשוי להיות שונה מהטיפוס הסטטי בהינתן הטיפוס הדינאמי עשויות להיות פעולות נוספות שניתן לבצע על העצם המוצבע )פעולות שלא הוגדרו בטיפוס הסטטי( כדי להפעיל פעולות אלו עלינו לבצע המרת טיפוסים )Casting( על ההפניה 28
המרת טיפוסים Cast המרת טיפוסים בג'אוה נעשית בעזרת אופרטור אונרי שנקרא Cast ונוצר על ידי כתיבת סוגריים מסביב לשם הטיפוס אליו רוצים להמיר. (Type) <Expression> )הדיון כאן אינו מתייחס לטיפוסים פרימיטיביים(. הוא מייצר ייחוס מטיפוס Type עבור העצם שהביטוי <Expression> מחשב, אם העצם מתאים לטיפוס. הפעולה מצליחה אם הייחוס שנוצר מתייחס לעצם מתאים לטיפוס Type המרה למטה :)downcast( המרה של ייחוס לטיפוס פחות כללי, כלומר הטיפוס Type הוא צאצא של הטיפוס הסטטי של העצם. המרה למעלה :)upcast( המרה של ייחוס לטיפוס יותר כללי )מחלקה או מנשק( כל המרה אחרת גוררת שגיאת קומפילציה. 29
המרת טיפוסים Cast public class A public class B extends A public class C extends B public class D extends A A B D C 30
המרת טיפוסים Cast המרה למעלה תמיד מצליחה, ובדרך כלל לא מצריכה אופרטור מפורש; היא פשוט גורמת לקומפיילר לאבד מידע A C c = A a = (A)c B D C 31
המרת טיפוסים Cast המרה למטה עלולה להיכשל: אם בזמן ריצה טיפוס העצם המוצבע לא תואם לטיפוס Type התוכנית תעוף )ייזרק חריג )ClassCastException A A a = C c = (C)a B D C 32
המרת טיפוסים Cast כל המרה אחרת גוררת שגיאת קומפילציה. ההגיון מאחורי זה: לא ניתן "לצמצם" אותו גם ל B וגם ל D. מכיוון ש B אינו אב קדמון של D ולהיפך, האפשרות היחידה שבה זה יעבור היא אם קיימת מחלקה אשר יורשת גם מ B וגם מ D, שזה כידוע לא יתכן. A B c = D d = (D)d B D C 33
טיפוסי זמן ריצה תעופת תוכנית היא דבר לא רצוי לפני כל המרה נרצה לבצע בדיקה, שהטיפוס אכן מתאים להמרה יש לשים לב כי ההמרה ב Java אינה מסירה או מוסיפה שדות לעצם המוצבע בזמן קומפילציה נבדק כי ההסבה אפשרית types( )compatible ואולי מתבצע שינוי בטבלאות השרותים שמחזיק העצם כאמור, בזמן ריצה המרה לא חוקית תיכשל ותזרוק חריג בדוגמא הבאה השאילתא maxside() מוגדרת רק למצולעים )ומחזירה את אורך הצלע הגדולה ביותר(. אין כמובן שאילתא כזאת במחלקה Shape )גם לא מופשטת(. כשהלקוח רוצה לחשב את אורך הצלע הגדולה ביותר מבין כל הצורות במערך, על הלקוח לברר את טיפוס העצם שהועבר לו בפועל ולבצע המרה בהתאם 34
טיפוסי זמן ריצה דרך אחת לבצע זאת היא ע"י המתודה getclass המוגדרת ב- Object והשדה הסטטי class הקיים בכל מחלקה: IShape [] shapearr =... double maxside = 0.0; double tmpside; for (IShape shape : shapearr) { if (shape.getclass() == Polygon.class){ tmpside =((Polygon)shape).maxSide(); if (tmpside > maxside) maxside = tmpside;? מה לגבי צורות מטיפוס Triangle או Rectangle עצמים אלה אינם מהמחלקה Polygon ולכן לא ישתתפו 35
instanceof האופרטור instanceof בודק האם הפנייה is-a מחלקה כלשהי - כלומר האם היא מטיפוס אותה המחלקה או יורשיה או מממשיה IShape [] shapearr =... double maxside = 0.0; double tmpside; for (IShape shape : shapearr) { if (shape instanceof Polygon){ tmpside =((Polygon)shape).maxSide(); if (tmpside > maxside) maxside = tmpside; 36
instanceof שימוש ב- Casting בתוכניות מונחות עצמים מעיד בדר"כ בעיה בתכנון המערכת )"באג ב )"design שנובעת לרוב משימוש לא נכון בפולימורפיזם על לעיתים אין מנוס משימוש ב- Casting כאשר משתמשים בספריות תוכנה כלליות אשר אין לנו שליטה על כותביהן, או כאשר מידע הלך לאיבוד כאשר נכתב כפלט ואחר כך נקרא כקלט בריצה עתידית של התכנית. 37
טיפוסי זמן ריצה הקוד בדוגמא הבאה אופייני ל"תרגום" קוד משפת C לשפת.Java הלקוח )כותב הפונקציה )rotate מקבל כארגומנט צורה גיאומטרית, ומנסה לסובב אותה בדוגמא זו, לא הוגדר שרות סיבוב במחלקה Shape )גם לא שרות מופשט( מכיוון שלכל צורה שרות סיבוב שונה, על הלקוח לברר את טיפוס העצם שהועבר לו בפועל ולבצע המרה בהתאם המחלקות Ellipse Polygon מממשות כל אחת פונקציה אחרת לסיבוב void rotate(ishape s, double degree) { if (s instanceof Polygon) { Polygon p = (Polygon)s; p.rotatepolygon(degree); ו return; if (s instanceof Ellipse) { Ellipse e = (Ellipse)s; e.rotateellipse(degree); return; assert false : "Error: Unknown Shape Type"; 38
instanceof כדי לתרגם את הקוד לא רק ל- Java אלא גם ל OO נשתמש במחלקה מופשטת )או מנשק( אשר תספק מנשק אחיד לעבודה נוחה עם כל צאצאי ההיררכיה כך יוכל הלקוח להשתמש באותו קוד עבור כל הצורות: void rotate(abstractshape s, double degree) { s.rotate(degree); 39
instanceof abstract class AbstractShape implements IShape { //... abstract void rotate(double degree); class Polygon extends AbstractShape { //... void rotate(double degree) { rotatepolygon(degree); class Ellipse extends AbstractShape { //... void rotate(double degree) { rotateellipse(degree); 40
טיפוסי זמן ריצה מימוש מתוקן void rotate(ishape s, double degree) { if (s instanceof AbstractShape) { AbstractShape as = (AbstractShape)s; as.rotate(degree); return; assert false : "Error: Unknown Shape Type"; ביצוע Casting ל AbstractShape וקריאה למתודה.rotate מתודה זו מומשה במחלקות Ellipse ו Polygon 41
Dynamic dispatch vs. static binding הפעלת שרותי מופע ב Java היא דינאמית: הקומפיילר לא מציין ל- JVM איזו פונקציה יש להפעיל )רק את החתימה שלה( בזמן ריצה ה JVM מפעיל את השרות המתאים לפי הטיפוס הדינאמי, כלומר לפי טיפוס העצם המוצבע בפועל הפעלה דינאמית מכונה לפעמים וירטואלית הפעלה דינאמית שכזו איטית יותר מתהליך שבו הקומפיילר, כחלק מתהליך הקומפילציה, היה מציין איזו פונקציה יש להפעיל ואז לא היה צורך לברר בזמן ריצה מהו הטיפוס הדינאמי ולהסיק מכך מהי הפונקציה שיש להפעיל מקרים שבהם הקומפיילר קובע איזו פונקציה תרוץ נקראים static binding )קישור סטטי( 42
אופטימיזציה: devirtualization במקרים מסוימים, כבר בזמן קומפילציה ברור שהטיפוס הדינאמי של הפנייה זהה לטיפוס הסטאטי שלה, ואז אין צורך בהפעלה וירטואלית MyClass o = new MyClass(); o.method1(5); // clearly o is a member of MyClass בקוד: למשל, ואולם לא את כל המקרים האלה יודע הקומפיילר לזהות יש מקרים שכן: אם MyClass מוגדר final או שהשירות method1 מוגדר במחלקה ;final זה מונע דריסה שלו הפעלת שרות private הפעלת בנאים הפעלת שרות super הפעלת שרותי מחלקה method(,static כפי שמרמז שמם...( במקרים כאלה, הקומפיילר יכול לבצע devirtualization ולהורות ל JVM איזו פונקציה להפעיל 43
public class Animal { public static void hide() { System.out.format("The hide method in Animal.%n"); public void override() { System.out.format("The override method in Animal.%n"); public class Cat extends Animal { public static void hide() { System.out.format("The hide method in Cat.%n"); public void override() { System.out.format("The override method in Cat.%n"); public class Client{ public static void main(string[] args) { Cat mycat = new Cat(); Animal myanimal = mycat; //myanimal.hide(); //BAD STYLE Animal.hide(); //Better! myanimal.override(); מה יודפס? The hide method in Animal. The override method in Cat. 44
public class Base { private void priv() { System.out.println("priv in Base"); public void pub() { System.out.println("pub in Base"); { public void foo() { priv(); pub(); { public class Sub extends Base { private void priv() { System.out.print ln("priv in Sub"); public void pub() { System.out.println("pub in Sub"); { public class Test { { public static void main(string[] args) { Base b = new Sub(); b.foo(); מה יודפס? priv in Base pub in Sub 45
שדות, הורשה וקישור סטטי גם קומפילציה של התייחסויות לשדות מתבצעת בצורה סטטית מחלקה יורשת יכולה להגדיר שדה גם אם שדה בשם זה היה קיים במחלקת הבסיס )מאותו טיפוס או טיפוס אחר( public class Base { public int i = 5; public class Sub extends Base { public String i = "five"; 5 five 5 public class Test { public static void main(string[] args) { Base bb = new Base(); Sub ss = new Sub(); Base bs = new Sub(); System.out.println(bb.i); System.out.println(ss.i); System.out.println(bs.i); מה יודפס? 46
העמסה והורשה במקרים של העמסה הקומפיילר מחליט איזו גרסה תרוץ )יותר נכון: איזו גרסה לא תרוץ( זה נראה סביר )הפרוצדורות מתוך :)java.lang.string static String valueof(double d) { { static String valueof(boolean b) { { overloaded(rectangle x) { { overloaded(coloredrectangle x) { { אבל מה עם זה? לא נורא, הקומפיילר יכול להחליט, Rectangle r = new ColoredRectangle (); ColoredRectangle cr = new ColoredRectangle (); overloaded(r); // we must use the more general method overloaded(cr); // The more specific method applies 47
העמסה והורשה אבל זה כבר מוגזם: overthetop(rectangle x, ColoredRectangle y) { { overthetop(coloredrectangle x, Rectangle y) { { ColoredRectangle a = new ColoredRectangle (); ColoredRectangle b = new ColoredRectangle (); overthetop(a, b); ברור שנדרשת המרה ) casting (אבל של איזה פרמטר? a או b? אין דרך להחליט; הפעלת השגרה לא חוקית בג'אווה 48
העמסה והורשה - שבריריות overthetop(rectangle x, ColoredRectangle y) { { overthetop(coloredrectangle x, Rectangle y) { { ColoredRectangle a = new ColoredRectangle (); ColoredRectangle b = new ColoredRectangle (); overthetop(a, b); אם הייתה רק הגרסה הירוקה, הקריאה לשגרה הייתה חוקית כאשר מוסיפים את הגרסה הסגולה, הקריאה נהפכת ללא חוקית; אבל הקומפיילר לא יגלה את זה אם זה בקובץ אחר, והתוכנית תמשיך לעבוד, לגרסה הירוקה ולקרוא לא טוב שקומפילציה רק של קובץ שלא השתנה תשנה את התנהגות התוכנית; זה מצב שברירי 49
העמסה והורשה - יותר גרוע class B { overloaded(rectangle x) { { class S extends B { overloaded(rectangle x) { { // override overloaded(coloredrectangle x) { { // overload but no override! S o = new S(); ColoredRectangle cr =... o.overloaded( cr ); // invoke the purple ((B) o).overloaded( cr ) // What to invoke? 50
class B { overloaded(rectangle x) { { class S extends B { overloaded(rectangle x) { { // override overloaded(coloredrectangle x) { { // overload but no override! S o = new S(); ColoredRectangle cr =... o.overloaded( cr ); // invoke the purple ((B) o).overloaded( cr ) // What to invoke? מנגנון ההעמסה הוא סטטי: בוחר את החתימה של השרות וסוג הפרמטרים(, אבל עדיין לא קובע איזה שירות ייקרא. )טיפוס העצם, שם השרות, מספר עבור הקריאה( ( B ))תיבחר o).overloaded( cr )בזמן קומפילציה( החתימה: B.overloaded(Rectangle) בגלל שיעד הקריאה הוא מטיפוס B השרות היחיד הרלבנטי הוא האדום! בזמן ריצה מופעל מנגנון השיגור הדינמי, שבוחר בין השרותים בעלי חתימה זאת, את המתאים ביותר, לטיפוס הדינמי של יעד הקריאה. הטיפוס הדינמי הוא, S לכן נבחר השרות הירוק. B b = new S(); b.overloaded( cr ) 51 כנ"ל אם הקריאה היא:
העמסה זה רע אם עוד לא השתכנעתם שהעמסה היא רעיון מסוכן, אז עכשיו זה הזמן בייחוד כאשר ההעמסה היא ביחס לטיפוסים שמרחיבים זה את זה, לא זרים לחלוטין יוצר שבריריות, קוד שמתנהג בצורה לא אינטואיטיבית )השירות שעצם מפעיל תלוי בטיפוס ההתייחסות לעצם ולא רק במחלקה של העצם(, וקושי לדעת איזה שירות בדיוק מופעל ומכיוון שהתמורה היחידה )אם בכלל( היא אסתטית, לא כדאי 52